In a credit-based flow control, a sender (e.g., a transmitter) can only transmit a packet to a receiver if the sender has credits to use. As such, when the sender runs out of credits, it must wait to get credits back from the receiver before transmitting another packet. When the receiver finishes processing the received packets from its buffer(s), it signals a return of credits to the sender, which increases the credit limit by the restored amount (e.g., up to a predetermined credit limit). The credits are stored in credit counters and decremented when used. When the credits reach the credit limit (i.e., when the available credits are zero), the sender stops transmitting packets. The advantage of this scheme (compared to other methods such as wait states or handshake-based transfer protocols) is that the latency of credit return generally does not affect performance, provided that the credit limit is not encountered. However, this assumption is not generally met.
One way to avoid the impact on performance (i.e., to avoid idle time of the sender and thus to avoid lower sender throughput) is to increase the number of credits (i.e., increase the credit limit) and/or the size of the receiving buffer. Increasing credit limit may require increasing the receiving buffer size to avoid a bottleneck at the receiver end. However, increasing the receiving buffer size is not possible dynamically as hardware is defined at the time of manufacturing and is a constant.